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ABSTRACT 



A method and apparatus for enabling AIX device driver 
(DD) created for a uniprocessor (UP) system to run 
unchanged on a syimuetiical multiprocessor system (SMP). 
Device drivers are processed by a funnelling mechanism so 
that UP device drivers always runs on a **Master^ processor 
in a multi-processor system. New device drivers written for 
the SMP system are permitted to bypass the funnding 
mechanism and proceed directly to execution on any avail- 
able processor in the SMP system. Device registration 
services arc provided which examine DD flags looking for 
a new unique flag indicating that the device driver is SMP 
enabled. If the flag is not present, then emulating a unipro- 
cessQT environment for execution of that device driver. 

12 Claims, 6 Drawmg Sheets 
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METHOD AND APPARATUS FOR DEVICE 
DRIVER FUNNELLING 

FIELD OF THE INVENIIGN 

The present invention relates to data processing systems, 
and more particularly, to device driver code execution that 
enables existing device drivers created for execution on a 
uniprocesscM- platform to run unchanged on symmetrical 
multi-processor platform* 

BACKGROUND OF THE INVENTION 

Multi-processing and iiiultitasking were oiiginaUy devel- 
oped in the mfiinframe world. Today, operating systems use 
various models of the IBM Virtual Machine (VM) architec- 
ture to in^ilcmcnt the concept, A preemptive multitasking 
operating system such as ADC, which is manufactured by the 
IBM Corporation, allocates memory partitions to create 
virtual machines for each running ^plication, and then 
divides the Central Processing Unit (CPU) dock into time 
slices (or time-ticks) so that each application receives CPU 
time on a round-robin basis. Preemptive means that appli- 
cations shifted to the background remain active to do such 
things as sort databases, print tiles, or exchange data with 
other computers, while a user works on a foreground appli- 
cation. 

Multi-processing poforms the same functions, except that 
applications and processes are time-sliced across more than 
one microprocessor- The process becomes a bit more com- 
plicated because the operating system kernel has to create 
memory locks down at the hardware level, and it must allow 
the operating system kernel to run across all CPUs. The 
operating system kernel accomplishes this by spirming off 
portions of itself to all the CPUs and managing fte allocation 
of system resources to applications as they are needed. 

Multi-processing can he implemented in two ways — as 
symmetrical multi-processing (SMP) and asymmetrical 
multi-processing (ASMP). SMP is the implementation of 
choice for many of today's server technologies. SMP bal- 
ances the workload dynamically across all CPUs in a 
round-robin fashion at each tick of the dock cycle. If the 
activity on one of the processors decreases, it automatically 
takes over excess threads running on other processors. 
Wority levds can be established for each application. For 
instance, if a payroll application has to run every Friday 
morning, it could be designated to have the higlhest priori^ 
level That means it will rccdve the lion's share of CPU 
time. 

Major work has been required to enable ADC to run on 
SMP systems, particularly in the area of device drivers 
which are c^>crating system kernel extensions. Device driv- 
ers enable devices to interact with the operating system 
kernel in the appropriate manner. ADC provides a mecha- 
nism for dynamically adding, removing or querying device 
driver entries in the form of a dynamically managed device 
switch table. The dynamic device driver switch table enables 
the addition or removal of device drivers without requiring 
the operating kcmd being rebuilt or the system rebooted. 
Traditionally, UNIX operating systems have provided stati- 
cally built-in device drivers. A dcvswadd service is provided 
in ADC to allow a device driver's configuration routine, the 
capability to add the device driver to the device driver switch 
table. A devswdel service is provided to allow a device 
. driver's termination routine to remove its entry from the 
device driver switch table prior to the device driver being 
unloaded from the kemd. A devswqry service is provided to 
query entries in the device driver switch table. This service 
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returns the state of the device switch table entry for a given 
major number. An intcmal dcvsw_Jnit kernel function is 
provided to initialize the dynamic device switch table during 
operating system kernel initialization 
5 Similariy, device drivers register interrupt handlers and 
other interfaces to the operating system kernel 

While the dynamic device driver switch table and other 
facilities have eliminated the need to reboot or rebuild die 
operating system kcind in multitasking system using a 
single processor or uni-processor system, it does not enable 
using device drivers built for uoiprooessor systems to be 
used on SMP systems. Existing uniprocessor device drivers 
must be converted to SMP device drivers, with the assod- 
ated cost and aggravations of having to convert all existing 
uniprocessor device drivers for SMP system operation. 

It is desirable to have an improved method and apparatus 
for enabling device drivers created for a uniprocessor system 
to be used unconverted on a symmetrical multi-processing 
system. 

20 

SUMMARY OF THE INVENTION 

This invention rdates to a method and apparatus for 
enabling ADC device driver created for a uniprocessor (UP) 
to run unchanged on a symmetrical multiprocessor system 

^ (SMP). ADC device drivers are operating system kemd 
extensions that are dynamically loaded to allow devices 
(e.g., printers, hard disks, floppy disks, etc.) to interact with 
the operating system kernel in the appropriate manner. This 
invention provides for the **funnellijag" of all device drivCT 
code execution so that uniprocessor device drivers always 
run on the '^Master" processor. Uniprocessor device drivers 
are placed in the SMP system without undergdng multi- 
processor (MP) serialization. New device drivers written for 
the SMP system are permitted to bypass the funneling 
mechanism and take advantage of multiple processors on the 
SMP system. A device registration service is provided to the 
operating system kernel. Flags are defined for each device 
driver enabling the determination of whether the device 
driver is a newly aeated SMP device drivcx or one of the 

^ existing uniprocessor device driver. Operating system ser- 
vices detect new SMP device drivers or existing uniproces- 
sor device drivers, Tbe UP device drivers are moved to the 
master processor for subsequent execution. This allows UP 
device drivers to be preserved and moved directiy to the 
SMP system, while SMP device drivers bypass the fimnding 
mechanism and proceeds diredly for multi-processor safe 
(MP Safe) execution on the SMP systems. 

BRIEF DBSCRIPnON OF THE DRAWINGS 

^0 fKj. 1 is a block diagram of an operating system illus- 
trating multiprocessor and uniprocessor device drivers on a 
multiprocessor platform. 

FIG. 2 is a flow diagram for device driver initialization on 
multiprocessor platform. 

FIG. 3 is a flow diagram for the invocation of a device 
driva through the config entry point 

FIG. 4 flow diagram for the invocation of device drivers 
through the device switch table entry poinL . 
gQ FIG. 5 is a flow diagram fci invocation of device drivers 
through the intemipt handler. 

FIG. 6 is a flow diagram of device driver invocation 
through tiie lODONE ( ) handler. 

FIG. 7 is a flow diagram for device driver invocation 
65 through the timer handler. 

FIG. 8 is a block diagram of a workstation for practicing 
the invention. 
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DETAILED DESCRIFnON OF THE routed to the Master processor 32 via line 28. The interrupt 

EMBODIMENTS handler dispatch 24 provides device driver dispatch in 

response to device inteirupts. Tlie interrupt handler dispatch 
This invention provides a method and apparatus for 24 determines if the requested device driver is MP-safe and 
enabling device drivers created for a uniprocessor platform ^ routes it to any available processor 32-^38 for execution, 
to be executed on a multiprocessor platform. Device Drivers Device drivers determined to be NOT MP_SAFE are fun- 
(DD) arc necessary to enable devices to interact with the ^eled to the Master processor 32 for execution. If a device 
operating system kernel in the appropriate manner: In the driver wishes to initiate an I/O request to be processed by 
preferred embodiment, which uses the AIX operating system another device driver, it invokes the "strategy** devsw entry 
kernel, device drivers are extensions of the operating system jq point of the desired device driver. The calling device driver 
kernel and are dynamically loaded to extend the capabilities provides an *TODONE0" function address to be called when 
of the operating system kernel When tiie need arose to the I/O request is convicted. This infonns the initiator when 
enhance the AIX operating system, by allowing execution the request is complete. For a uni-processor device driver, 
on symmetrical multi-processing (SMP) systems, significant the invocation of the lODONEQ function must be performed 
work was necessary to extend the operating system capa- on the Master processor 32. A new flag "B_MPSAFE" is 
bilities. The problem was how to use the large numbers of added so the initiator of an I/O request can indicate that 
existing device drivers created for uniprocessor (UP) sys- initiatCM* is MP Safe, and that the lODONEQ function can be 
tems. This invention allows the preservation of customer executed on any processor. Absence of the flag implies that 
investments in existing UP device drivers by minimizing the initiate's lODONEQ function can only be executed on 
device driver porting, and at the same time enabling the the Master processor 32. The IODONE function is called by 
introduction of new SMP device drivers. The invention will the IODONE Handler Dispatch 26. 
be described more completely in reference to die following operating system kernel timer handler dispatch 18, 
drawings. docs not have provisions for directing device driver exccu- 
Turning to FIG. 1, there is shown a block diagram of the tion. The timer function is always invoked on the same CPU 
invention in an SMP system 10. The SMP system 10 has an 25 that the timer was started on. In the case of a uniprocessor 
operating system kernel 14 for routing device driver execu- device driver, its code execution, due to the results of the 
tion to any one of N available processors 32-38, Processor present invention, is guaranteed to only be on the Master 
0 (32) is the master processor in a chain of N possible processor 32. Therefore, any timers started by a uni- 
processors available for executing instmctions in the SMP processor device driver will have been started on the master 
system. One skilled in the art appreciates that the operating 30 processor and subsequentiy, the execution of the timer 
system picks one of the "N" possible processors as the handler would also be on tiic master processor. Multipro- 
master, and ensures that all funnelled code run on that cesser device drivers can be executing on any processor, 
processor. This ensures that there will never be multi- thus starting and handling timers on any processor, 
processing (MP) unsafe code running on more than one Turning now to FIG. 2, there is shown a flow diagram for 
processor. Uniprocessor device drivers 12, and multi- 35 device driver initialization using the invention. The proce- 
processor device drivers 13, are available to the operating dure for initialization of a uniprocessor, nonMP Safe device 
system kernel 14 for routing to processors 32-38. The driver, starts at block 40. Here, the procedure uses the 
system configuration (sys config) dispatch 16 procedure devswadd service to register the device driver's open(), 
always funnel device driver execution via line 28 to pro- close(), readO, writeQ, ioctiO, strategyQ, selectQ, configO, 
cessor 0 (32) which is the master pxtcessor. The sys config 40 printQ, dunq)0, mpxOt and revokc() entry points with the 
dispatch 16 procedure is invoked when a device driver is operating system, in a manner known in the art. The details 
being loaded and initialized. Device drivff switdi table 20, of each entry point is not relevant to the invention, except the 
provides for device driver execution exclusively on master fact that these entry points are invoked by the operating 
p-ocessor 0 (32) via line 28, or any available processor 0-^ system on behalf of an application or other kernel extension 
(32^38) via line 30. Device driver switdi table 20 dctcc- 45 or device driver for the propose of perf arming VO, or other 
mines if the device driva: executes on the master processor requests to a device. In block 46, the operating system sees 
(32), by examining a flag, as associated with the device that the DEV_MPSAFE flag is not set during registration 
driver. If the device driver flag indicates that the device and marks the device entry to be funndcd. This means that 
driver is multi-processor safe (MP_SAFE), execution on all accesses to this device through the device switch table 
the device driver occurs on any available processor 32-^38 50 will be executed on die Master processor 32. At block 48, the 
via line 30. Table A gives an example of the types of flags device driver registers an interrupt handler to the operating 
contemplated by this invention. As disclosed in Table A, system to be called when the operating system receives an 
column 1 gives the DEVSW location of the available device external interrupt on behalf of this device. The operating 
drivers. Column 2 describes the device type, such as system sees that the INTR_^MPSAFE flag is not set during 
NVRAM, SCSI, Floppy Diskette or Ethernet Adapter. Col- 55 the interrupt handler registration and routes all device inter- 
unm 3 illustrates the DEVSW flags which are MP safe for nipts for this device to the Master processor 32. If the device 
the SCSI and Ethernet Adapter and not MP safe for NVRAM driver initiated an I/O request as depicted in block 52, the 
and Roppy Diskette. CoUimn 4 shows the presence or operating system will call the initiator's lODONEQ handler 
absence of interrupt flags for each device driver. Finally, upon completion of the I/O request In block 54, the oper- 
Column 5 illustrates the buffer flags on a sample read. The ^ system sees that the B_MPSAFE flag for this I/O 
presence of an MP_jSAFE flag in this column indicates that request is not set and will reroute execution of this 
the device driver can be executed on any one of "N'* I0DONE()handlcrto the master processor. Moving to block 
processor. Likewise, the absence oftheMP_SAFE indicates 42, the procedure for initialization of a multiprocessor 
that device driver execution is possible only on the master enabled device driver is shown, In block 56, the multipro- 
processor 32. 65 cesser enabled device driver sets the DEV_MPSAFE flag 
Returning to FIG. 1, if a device driver is determined to be and allows all accesses to this device driver's entry points to 
NOT multi-processor safe (NOT MP^AFE), execution is execute on any processor. When the multiprocessor enabled 
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device driver registers an itttemipt handler to the operating 
system, as in block ^0, it sets the mK31PSAFE flag, 
whidi when noticed by the operating system in block 62, 
allows routing of it s device intenupts to any available 
processor If the multiprocessor enabled device driver ini- 5 
tiates an VO request as in block 64, it sets the B_J4PSAFE 
flag of the I/O request information block to indicate that the 
lODONEO handler for this request can be executed on any 
available processor. 



and lengdi of the buffer in system memory to transfer data 
to or from, the I/O device and offset of the device to transfer 
data to or from, the lODONEQ function to invoke when the 
I/O is complete, flags indicating the direction of the transfer 
(B_jyaAD, B_WRirE) and whethtt the lODONEQ han- 
dler is MP Safe (B_>IPSAFE), as wdl as other relevant 
information. If the operating system detennines that the 
lODONEO handler is not MP Safe, due to the absence of the 
B_MPSAFE flag in the 110 request information block, the 



TABLE A 



Device 
DEVSW type 



DEVSW 
Flags 



Ihtenupt 
Hags 



BuSerFlAgs 
on Sample Read 



0 NVRAM DEVJEFINED 

1 <cniptf> DBV_JTOT_DEFINED 

2 SCSI DBV_J)EEINED 
Adapter DBV_MPSAFE 

3 Floppy DBV_I)EFINED 
Diskette 

4 Ethernet nEV_JDEFINED 
Adapter DEV_MPSAFE 



B_READ 

<□□ iaterpipt> <Dot_appIicabk> 

DOK-LEVEL B_READ 

IKIK_MPSAFE B_>IPSAFE 

IWnL_EDC3E B__READ 

INTR_iEYEL B__READ 

INTFL_MPSAFE B_NffSAFE 



With reference to FIG. 3, there is shown a flow diagram 
using the conflg entry point. The procedure began at block 
70 and proceeds to block 72, where the operating system 
receives the system configuration system calL At block 74, 
the operating system routes the execution path to the master 
processor. System conflguration processing is finished at 
block 76 and the procedure ends at block 78, 

Ttoning now to FIG. 4, a flow diagram is shown for 
invocation of a device driver switch table cntiy point via 
operating system calls sudi as openQ^ doseQ, readQ* write 
0, or other similar operating system iaterfeces. The proce- 
dure starts at block 89 where the devsw service is accessed 
using one of the system calls. At block 82. the operating 
system receives the open, read, write, etc, system call. At 
block 84, the procedure checks to see if the selected device 
driver is MP_SAFE. If NO, at block 86, the procedure 
causes the operating system to reroute execution of flie 
selected device driver to the master processor. Returning to 
block 84, if the device driver is MP_SAFE, processing 
continues at block 88 where ^e procedure finishes system 
call processing on the current processor and the procedure 
ends at block 90. 

Turning now to FIG. 5, a flow diagram is shown for 
invocation of the device driver using the intenrupt handler. 
R-ocessing starts at block 92 where an intemipt is detected. 
At block 94, the operating system receives the external 
device interrupt The interrupt request is then checked to 
determine if the interrupt is MP JAFK If YES, processing 
proceeds to block 100. Else, at block 98, the procedure 
reroutes execution of the device driver to the master pro- 
cessor. At block ioO, the procedure finishes interrupt pro- 
cessing on any available processor and terminates at block 
102. 

With reference to FIG. 6, a flow diagram is shown for 
invocation of a device driver's lODONB handler. An 
lODONEQ handler is provided by the initiator of an 1/0 
request, and is invoked by the operating system upon 
completion of the VO request Processing starts at block 112, 
where the operating system receives completion of an 1/0 
request. Each 1/0 request is described by an I/O request 
information block. This information block contains neces- 
sary information about the 1/0 request including the address 



25 

operating system reroutes execution of the lODONEQ han- 
dler to be on the Master processor 32, as shown in block 116. 
Other wise, if in block 114, the operating system detects that 
the lODONEQ handler is MP Safe due to the presence of the 
30 B^JdPSAFE flag, it allows execution of the lODONEQ 
handler on any available processor. 

Turning now to FIG. 7, a flow diagram is shown for 
invocation of device drivers timer handler. The procedure 
starts at block 122 and proceeds to block 124 where the 
35 device driver starts a system timer. At block 126, the 
operating system starts a system timer on the cunently 
executing processor. Note that a funnelled device driver 
would be executing on die master so therefore timer execu- 
tion fiinneling is already handled since the timer execution 
40 of the timcx- handler will be on the same processor that 
started the timer. The timer expires at block 128 and the 
opaating system invokes the timer handler at blodc 130. 
The procedure ends at block 132. 
Ttmiing to FIG. 8, the invention is preferably practiced in 
45 the context of an <^>erating system resident on an IBM 
computer/woikstation (e.g., RS/6000 or PS/2 manufactured 
by the IBM Corporation). A representative hardware envi- 
ronment is dq>icted in FKj. 8, which illustrates a typical 
hardware configuration of a workstation in accordance with 
50 the subject invention having multiple central processing 
units 9, 10, and 11, such as conventional microprocessors, 
and a number of oth^ units interconnected via a system bus 
12. The workstation shown in FIG. 8 includes a Random 
Access Memory (RAM) 14, Read Only Memory (ROM) 16, 
55 an I/O adapter 18 for connecting peripheral devices such as 
disk unit 20, capable of receiving computer readable 
medium to the bus, a user interface adapter 22 for connect- 
ing a keytx)ard 24, a mouse 26, a speaker 28, a microphone 
32, and/or other user interface devices such as a touch screen 
60 device (not shown) to the bus, a communication ad^ter 34 
for connecting the workstation to a data processing network 
and a display adapter 36 for connecting the bus to a display 
device 38. The workstation has resident thereon the ADC 
operating system or an equivalent operating system execut- 
ing on an SMP platform. 

While the invention has been descrit>ed with respect to a 
preferred embodiment thereof, it will be understood by those 
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skOled in the art that various dianges in detail may be made 
therein without dej>arting £rom the spirit, scope, and teach- 
ing of 'the inventioD. Accordingly, the herein disclosed 
invention is to be limited only as specified in the following 
claims. 5 
What wc claim is: 

1. A method for executing device drivers on a multipro- 
cessor platform having a plurality of processors including a 
master processor, wherein said device drivers were created 
for execution on a uniprocessor platform, con^dsing: lO 

receiving an inteuupt for a selected one of said device 
drivers into said multiprocessor platform; 

determining if the selected one of said device drivers is 
created for execution on said uniprocessor platform by 
the presence or absence of a flag on said selected one 
of said device drivers; 

executing the selected one of said device drivers only on 
said master processor of said multiprooessor platform 
when the selected one of said device drivers is deter- 
mined to be created for said uniprocessor platform; and 

executing said device drivers on any one of said plurality 
of processors in said multiprocessor platform when not 
created for said uniprocessor platform. 

2. The method of claim 1 wherein said step for receiving 25 
said device drivers include an operating system on said 
multiprocessor platfonn. 

3. Hie method of claim 1 wherein said step for determin- 
ing includes a step for registering said device drivers in said 
operating system based on a user supplied flag. 30 

4. The method of claim 3 wherein said step for registering 
includes a step for posting a MP_SAFE flag for device 
drivers not created for said uniprocessor platfcrm. 

5. An apparatus for executing device drivers on a multi- 
processor platform having a plurality of processors includ- 35 
ing a master processor, wherein said device drivers were 
created for execution on a uniprocessor platform, compris- 
ing: 

means for receiving an interrupt for a selected one of said 
device drivers into said multiprocessor platform; 40 

means for determining if the selected one of said device 
drivers is created for execution on said imiprocessor 
platform by the presence or absence of a flag on said 
selected one of said device drivers; 

means for executing the selected one of said device 
drivers only on said master processor of said multipro- 
cessor platform when the selected one of said device 
drivers is determined to be created for said uniproces- 
sor platform; and 



means for executing said device drivers on any one of said 
plurality of processors in said multiprpcessor platform 
when not created for said uniprocessor platform. 

6. The apparams of claim 5 wherein said means for 
receiving said device drivers include an c^>erating system on 
said multiprocessor platform. 

7. The apparatus of claim 5 wherein said means for 
determining includes a means for registering said device 
drivers in said operating system based on a user supplied 
flag. 

8. The apparatus of claim 7 wherein said means for 
registering includes means for posting a MP_SAFE flag for 
device drivers not created for said uniprccessor platform. 

9. A computer program product having a computer read- 
able medium having computer program logic recorded 
thereon for executing device drivers on a multiprocessor 
platform having a plurality of processors including a master 
processor, wherein said device drivers were created for 
execution on a uniprocessor platform, comprising: 

computer readable mediimi means for receiving an inter- 
rupt for a selected one of said device drivers into said 
multiprocessor platform; 

computer readable medium means for dctcrmimng if the 
selected one of said device drivers is created for 
execution on said uniprocessor platfonn by the pres- 
ence or absence of a flag on said selected one of said 
device drivers; 

computer readable medium means for executing the 
selected one of said device drivers on said master 
processor of said mult^ocessor platfonn when the 
selected one of said device drivers is determined to be 
created for said uniprocessor platfonn; and 

conqjuter readable medium means for. executing said 
device drivers on any one of said plurality of processors 
in said multiprocessor platform when not created for 
said uniprocessor platform. 

10. The con^ter program product of claim 9 wherein 
said computer readable medium means for receiving said 
device drivers include an operating system on said multi- 
processor platform. 

11. The conqjuter program product of claim 9 wherein 
said computer readable medium means for determining 
includes a means for registering said device drivers in said 
operating system based on a user supplied flag. 

12. The computer program product of claim 9 wherein 
said computer readable medium means for registering 
includes means for posting a MP_SAFE flag for device 
drivers not created for said uniprocessor platform. 
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